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ABSTRACT 


This thesis conducts an analysis of the system requirements for the Logistics 
Analysis and Wargame Support Tool (LAWST). It studies the process used to develop 
those requirements and potential requirements if a systems engineering (SE) approach 
had been used. The original requirements for LAWST are found in documentation 
provided by the Marine Corps Expeditionary Energy Office (E20) along with 
information indicating the sources of those requirements. As it is designed, LAWST may 
only be useful for a narrow scope, such as supporting seminar-type wargames where time 
is not a driving factor, while E20 is looking for a tool that is useful at the tactical edge to 
support wargaming as part of a high-paced planning process. A method based on the SE 
process is used to determine what the requirements for LAWST would be using this 
approach. When a system is developed using a set of requirements developed through an 
SE approach, it can address customer needs more completely and be produced at greater 
long-term cost savings than a system that has an incomplete set of requirements 
necessitating additional development. We recommend that E20 adopt a method for 
generating requirements based on the SE process for any future development. 
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EXECUTIVE SUMMARY 


The Logistics Analysis and Wargame Support Tool (LAWST) was developed for 
the Marine Corps Expeditionary Energy Office (E20) to use during the Expeditionary 
Eorce (EE)-21 Energy Study Operational Reach Wargame in 2015. The primary focus of 
the EAWST is to examine the fuel consumption of the logistics network to better 
understand the total energy demand of all forces operating in some area of operations. The 
Eogistics Analysis and Wargame Support Tool is designed to complement the Marine Air- 
Ground Task Eorce (MAGTE) Power and Energy Model (MPEM), which models the 
energy consumption of various Marine Corps formations while deployed, whereas EAWST 
specifically examines the logistics network that supports those formations. However, a 
previous study reveals that EAWST does not satisfy stakeholder objectives and is in poor 
position to pass verification and validation needs. Eindings from this past study stem from 
the vague definition of the system requirements. 

Our research focuses on the system requirements for EAWST. The three primary 
objectives of the research are: to determine how the system requirements for EAWST were 
established, to determine what the requirements for EAWST would be had a systems 
engineering approach been used, and to determine the extent to which EAWST would meet 
requirements developed using a systems engineering approach. Additionally, the research 
compares the original requirements to a set of requirements developed using a systems 
engineering approach. It quantifies the difference in the two requirements sets. These 
requirements are the key link in the validity of the current system in meeting its original 
purpose. 

The original purpose for EAWST is not explicitly articulated. However, there are 
eight presumed requirements that could be found in informal documents provided by E20 
and the primary contractor for the system. The process used to develop those requirements 
is unclear, but the most direct linkages are to the questions posed in the EE-21 Energy 
Study and Operational Reach Wargame. EAWST meets four of the eight requirements and 
partially meets three others. There is little evidence that these presumed requirements are 
for the current version of EAWST and no trade-off analysis for any of these requirements. 
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There is no documented proof that LAWST meets its original purpose. These findings are 
consistent with an internal report that the Naval Postgraduate School provided to E20. The 
report focused on the readiness of LAWST to undergo a verification and validation 
process. 

A set of requirements was developed using a systems engineering approach. That 
approach consisted of defining the problem, analyzing the system’s mission, determining 
the functions that the system needs to perform while conducting the mission, and 
developing requirements based on the mission and functional analysis. The process led to a 
set of 45 unique and traceable requirements that mapped back to the problem statement 
derived from needs and desires of the E20. 

The requirements developed using a systems engineering approach differ 
significantly from the original requirements for LAWST in both quantity and type. Most 
notably, the requirements developed using a systems engineering approach include 
nonfunctional requirements such as usability and interoperability as well as other functional 
requirement types, such as optimization. LAWST could meet 24 of those 45 requirements, 
but only partially meet the usability, interoperability, and optimization requirements. 
Additionally, as demonstrated using LAWST as an example in this research, the increased 
cost of developing a system with incomplete requirements and later changing those 
requirements is generally more expensive than developing a system using a more complete 
set of requirements in the beginning. 

The primary recommendation from this research is that E20 adopt a more robust 
process for developing system requirements prior to committing additional resources to 
those future developments. A recommended framework for developing those requirements 
is based on the systems engineering process, which is also recommended by the 
Government Accountability Office (GAO) to reduce system costs due to unidentified 
requirements being identified after a system begins development (Government 
Accountability Office 2015). 

The methodology of this research is founded on the systems engineering process, 
specifically the methods for requirements generation. The steps for that method as used in 
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this thesis are problem definition, mission analysis, functional analysis and developing 
requirements. Every system has a purpose for its development, which is summed up in the 
problem definition that is produced after a careful analysis of the customer’s needs. In this 
case, E20 is looking for a tool that will help plan, analyze, and optimize logistics networks 
for tactical units. The mission analysis, for the most part, focuses on the environment where 
a system resides and tasks that an operator will use the system to perform. The functional 
analysis determines the specific actions or functions that a system must perform as 
articulated by the task in the mission analysis. This includes both the tasks specified during 
the mission analysis and tasks that are implied by the environment and the interaction with 
the operator and other systems. The requirements are pulled directly from both the mission 
analysis and functional analysis. Those 45 requirements produced in this research are a 
basis for the development of a system. Additionally, it makes an effort to clearly show the 
requirements for the current system and their origin by examining the existing 
documentation from EAWST that was provided by E20. The research then outlines a brief 
analysis of EAWST showing the extent to which the system meets both sets of 
requirements and where the shortcomings are for the system, as well as comparing the 
requirements sets to each other. Those differences are quantified by comparing both the 
resource investment needed to produce the system and the extent to which the system 
addresses the capabilities that the customer desires in the product. 

Ultimately the research shows that, based on the original requirements, EAWST is 
insufficient to address the tasks that E20 wants it to do. EAWST does provide presumably 
useful information in evaluating logistics networks to determine the additional energy 
demand produced by the distribution of resources to operational units. However, EAWST 
is not sufficient to support battalions and brigades in planning, analyzing, and optimizing 
logistics networks during time-constrained planning windows in support of tactical 
operations. 

Reference 

Government Accountability Office. 2015. Defense Acquisition Process; Military Service 
Chiefs ’ Concerns Reflect Need to Better Define Requirements before Programs 
Start. GAO-15-469. Washington, DC: U.S. Government Accountability Office. 
June. 
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I. 


INTRODUCTION AND BACKGROUND 


A. PURPOSE 

This research will articulate the ramifications to system utility when a systems 
engineering (SE) approach is not applied in requirements development. It will establish 
an actionable framework to develop requirements that are appropriate, to the greatest 
extent possible, and traceable to an overarching problem or gap for which a system is 
developed. Furthermore, a system developed using a systems engineering process, that is 
verified to meet said requirements, is also more likely to be valid in addressing the 
problem for which it was developed. 

B. SCOPE 

The focus of this research is to examine the system requirements development 
process for LAWST. The research will examine the problem(s) that the system was 
designed to address. It will examine the various uses for the system and the environment 
in which it will be used. Additionally, it will examine the various documents describing 
modeling, software, and verification and validation (V&V) within the Marine Corps and 
DOD to determine additional considerations in the requirements generation. The specific 
research questions that this thesis answers are as follows: 

1. How were the design requirements established for the development of 
LAWST? 

2. What would the system requirements for LAWST be if a systems 
engineering approach had been used? 

3. Does the current version of LAWST address the system requirements that 
would have been developed through a systems engineering approach? 

The boundaries of the problem (the use of systems engineering in system design) 
that this research addresses extend beyond the software and documentation for LAWST 
and the E20’s specific issues. The problem(s) that LAWST potentially addresses impact 
everything from strategic logistic operations down to the energy demands at the company 
level. It also looks at the force structure of the logistics elements that support the 

distribution of fuel and other supplies to the tactical edge. A number of documents 
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outline guidance for modeling and simulation (M&S) development and verification, 
validation, and accreditation (VV&A) activities including MIL-STD-3002 
Documentation of VV&A for M&S, DoDI 5000.61 DOD Modeling and Simulation 
(M&S) Verification, Validation, and Accreditation (VV&A), DoDI 5000.59 DOD M&S 
Management, SECNAV Instruction 5200.38A and Marine Corps Order 5200.28A both 
for M&S Management. LAWST is also subject to planning doctrine such as the MCWP 
5-1, Marine Corps Planning Process, as it is a tool that may support wargame activities 
and analysis. 

C. BACKGROUND 

1. LAWST Description 

LAWST is a simulation built as a deterministic model to help planners and 
logisticians ascertain the feasibility of a specific course of action from a logistics supply 
standpoint. According to the capability summary, LAWST is “designed to assist with 
operational planning and the conduct of wargames” (Group W, unpublished document). 
It models the distribution of supplies in a given area of operations with a user defined set 
of distribution assets and nodes within a distribution network in order to estimate the 
quantity of supplies (primarily fuel) that will be consumed by the logistics process itself 
in servicing the supply needs of the warfighters. Ligure 1 shows a screenshot of a 
notional simulation scenario. 
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This shows a map of the area of operations along with graphs and information related to 
distribution assets and levels of supply. 

Figure 1. Screen Shot of LAWST Simulation. Source: LAWST Capability 
Summary (Group W, unpublished document). 


The graphical user interface displays a map, or more specifically, an image of a 
map over-laying a latitude/longitude or MGRS reference system rather than a geo- 
rectified map (LAWST accepts image files for this purpose). The user manually adds 
locations for supply nodes and transportation (e.g., roads) arcs between the nodes. While 
the arcs do not necessarily follow known routes on the map, the user can/may adjust 
factors to reflect the distance and time required to traverse the route during various 
operational conditions. The rates of consumption by tactical units (determined by 
MPEM) as well as logistics nodes are entered manually along with type of supplies and 
quantifying features of the supplies such as weight and volume. 

2. Verification, Validation, and Accreditation 

The verification, validation and accreditation (VV&A) process, is a mechanism 
by which models and simulations are certified to be used for some specific purpose. 
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Military Standard 3022, describing the standard practice for the VV&A for models and 
simulations, gives the following definitions for verification, validation and accreditation: 

Verification. The process of determining that a model, simulation, or 
federation of models and simulations implementations and their associated 
data accurately represents the developer’s conceptual description and 
specifications. 

Validation. The process of determining the degree to which a model, 
simulation, or federation of models and simulations, and their associated 
data are accurate representations of the real world from the perspective of 
the intended use(s). 

Accreditation. The official certification that a model, simulation, or 
federation of models and simulations and its associated data are acceptable 
for use for a specific purpose. (Modeling and Simulations Coordination 
Office 2012) 

In addition, DOD Instruction 5000.61 states that data associated with M&S that is 
used to support DOD activities shall go through a V&V process on a regular basis and be 
accredited for an intended use. Components are authorized to tailor the VV&A processes 
as necessary within the guidance from the instruction (Under Secretary of Defense 
[AT&L] (USD[AT&L]) (2009)). 

In 2016, the Marine Corps E20 requested that the Naval Postgraduate School 
(NPS) conduct an assessment of the readiness of LAWST to undergo a V&V process. 
The report aimed to inform E20 if the simulation was ready to move through a more 
formal V&V process to be accredited for use, and to make recommendations for 
improvements to the simulation as it is developed. 

The V&V assessment of EAWST is based on implied current and future uses 
rather than on explicitly stated system requirements (Hall 2016). The implied uses are 
based on the current version of EAWST as it exists. The V&V assessment addresses the 
question, “To what extent does EAWST do what it does?” rather than the more correct 
question: “To what extent does EAWST do what it was designed to do?” As stated in the 
V&V assessment: 

The requirements that drove these designs goals are neither specified here 
nor characterized by how well each of these functions would need to be 
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performed in order to satisfy those requirements beyond the stated intent 

to ‘support’ CO A generation and live wargame support. (Hall 2016) 

Professor Hall describes how the lack of formal requirements and specifications makes it 
virtually impossible to perform a VV&A assessment of the simulation. The absence of 
traceability and objectivity of current capabilities or direction for future capabilities or 
changes to the system as it moves further along in development is a significant issue 
(Hall 2016). 

The set of system requirements for the development of LAWST is undefined, 
thereby complicating, and perhaps precluding, the ability to proceed with its verification 
and validation. The ability to establish use cases for the end user that could lead to its 
accreditation is limited by the lack of context in which the system was developed. 
Evidence of any formal or documented process used to generate system requirements for 
the design and development of LAWST is unknown. 

D. OBJECTIVES 

This research will determine the system requirements for LAWST using an SE 
approach and to what extent LAWST meets those requirements. The objective of this 
research is threefold: to determine how the system requirements for LAWST were 
established, to determine what the requirements for LAWST would be had a systems 
engineering approach been used, and to determine the extent to which LAWST would 
meet requirements developed using a systems engineering approach. 

The current instance of LAWST was developed to support the EL-21 Operational 
Reach 15 wargame according to Group W records. The set of current informal system 
requirements was obtained from the Marine Corps E20 office which oversees the 
development of the model. This informal approach to requirements development, that 
will be discussed in chapter IV, section D, results in a system that is inadequate to meet 
the needs of the stakeholder. 

Our results articulate the ramification of not using a systems engineering 
approach to requirements development. Namely, LAWST does not meet E20 system 
objectives. LAWST is not postured to meet the demands of VV&A because there is little 
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documentation on the process used in designing the system. Furthermore, the E20 
requirements development provides an inadequate foundation for valid improvements to 
LAWST or as a means to assess the degree LAWST meets E20 needs. 
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II. LITERATURE REVIEW 


System requirements come from a variety of sources and can be determined in a 
number of ways. The types of requirements vary from system to system and between 
types of systems. For instance, the requirements for a pen seem straight forward; 
however, they may vary depending on the context in which the pen will be used. 
Different requirements would be necessary for a pen used in space, as opposed to one 
used in a classroom. In other cases, two completely different objects can have the same 
requirements. A calculator and a slide rule are vastly different objects, used for many of 
the same purposes. While requirements themselves vary, requirements generation should 
follow a logical process such as systems engineering, regardless of the system or type of 
system. 

A. IMPORTANCE OF ACCURATE REQUIREMENTS 

Accurate requirements are critical in every aspect of designing, building and 
testing a system. Requirements that describe what a system must do and to what degree it 
will provide those capabilities, provide developers and testers with an objective in 
building, and measures to evaluate a system. In the case of LAWST, Professor Hall 
(2016) describes the validation as being “made more difficult” by the lack of precision in 
defining what the system is supposed to do. The conceptual model that is provided with 
LAWST gives limited detail with respect to requirements other than “provide timely 
analytical support to wargames in which energy usage and distribution are of interest” 
(Group W, unpublished document). This statement does not specify measures of how 
fast, what type of analysis, or any useful information in designing or evaluating the 
system. More importantly, tracing from where this and other system requirements are 
derived is a challenge, but it is worth the time and effort. When a system is developed to 
a specific set of requirements and delivered to the customer, it is important that the 
system actually addresses the purpose that the customer desires. 

Blanchard and Fabrycky (2011) outline a method for requirements definition in 
Figure 2. It shows a systems engineering process to decompose the problem into a set of 
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system specifications that can be used for further research, simulation design, and 
enhancements. Central to this approach is properly defining the problem for which a 
systems engineering approach is applied. 
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Figure 2. System Requirements Definition Process. Source: Blanchard and 

Fabrycky (2011). 


The requirements generation process is the initial entry into the Systems 
Engineering “Vee,” as seen in Figure 3, where the problem and needs are decomposed 
into system specifications leading into the design of the system. System requirements are 
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a critical component in the design as well as the V&V after the system realization when it 
begins to take shape. 



Figure 3. The Systems Engineering “Vee.” Adapted from Defense Acquisition 

University (2017). 


The systems engineering approach follows a logical, iterative, and recursive 
process that captures all the aspects of the system through its life cycle. The process will 
not only capture system functions and measures, but also include other system 
interactions, “-ilities” (such as interoperability, usability, supportability), and other 
administrative requirements. The SE requirements generation process ensures that often 
overlooked constraints on the system design, derived from the environment and other 
external systems with which it is to operate, are considered. 

Current LAWST documentation does not confirm a specific problem definition 
used to begin its development. There are limited resources to develop these types of tools, 
and being able to justify specific capabilities is important to stakeholders. Therefore, it is 
critical for this system to be built upon a solid foundation of an appropriate problem 
definition and an accurate set of traceable requirements. These are the basis of a credible 
V&V for both the simulation and future improvements. 

Every organization determines its own way of generating requirements that suits 
its timelines, resources, and way of doing business. Eigure 4 outlines the Air Eorce Space 
& Missile Systems Center’s (SMC) process for creating system requirements (2005). 
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Figure 4. SMC Requirements Analysis Process. Source: SMC (2005). 


This SMC process (Figure 4) is quite similar to that which Blanchard and 
Fabrycky describe in Figure 1. The verbiage does not quite line up between the two 
processes, but the basic concepts are the same. Figure 5 maps the elements of the 
Blanchard and Fabrycky process to the SMC process. 
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Figure 5. Comparison of SMC and Blanchard and Fabrycky Descriptions of 
Requirements Generation. Adapted from SMC (2005) (right) and 
Blanchard amd Fabrycky (2011) (left). 


The processes described in Figure 5 can be summarized in five steps: problem 
definition, mission analysis, functional analysis, performance requirements, and 
requirements trade-off. This process is central to the research in this thesis. Further 
exploration of the steps can clarify the process. 

(1) Problem Definition 

Problem definition, or what Blanchard and Fabrycky (2011) call “Problem 
definition and identification of need” (74) and SMC (2005) calls “Customer needs and 
other process inputs,” (46) describes the purpose behind developing the system. Raw 
customer inputs, sometimes called primitive needs statements, are analyzed to determine 
what the actual problem is and why the problem exists. This is the starting point for 
developing requirements. 
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(2) Mission Analysis 

Mission analysis, what Blanchard and Fabrycky call “Operational requirements” 
and “Maintenance and support concepts” and SMC calls “Mission and Environmental 
Analysis” in essence, describes what the system needs to do and the context within which 
it will operate. This step should lay out the concept of operations for the system, 
including scenarios and vignettes describing how it is used, for what, by whom, where 
and why. 

(3) Functional Analysis 

Functional analysis is somewhat similar in that both the Blanchard and Fabrycky 
text and SMC handbook refer to this as “Functional analysis and allocation,” but SMC 
adds another step: “Functional Requirements Identification.” The Functional analysis 
decomposes the system into functions that it will be required to do to address the 
problem, as stated during Problem Definition, while doing the mission or tasks described 
in the mission analysis. 

(4) Performance Requirements 

In this step, called “Technical performance measures” and “Performance 
Requirements and Design Constraints Definitions/Refinement” by Blanchard and 
Fabrycky and SMC respectively, additional requirements are added that describe how 
well the system must perform the functions described in the functional analysis. In 
addition to describing the functions, additional requirements may be added in this step 
that describe how well, in terms of quantifiable measures, the system must perform in its 
mission. 

(5) Requirements Trade-off 

Blanchard and Fabrycky call this “System trade-off analysis” while the SMC puts 
it in a “Requirements Foop.” This step is often overlooked in system development to the 
detriment of the customer procuring the system. One GAO report on the Defense 
Acquisition Process expresses concerns from the service chiefs and other senior leaders 
that there is a lack of a systems engineering approach to requirements, specifically aimed 
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at what technology and resources are available for a system (GAO 2015). A careful 
analysis needs to look at the resources that the customer has and the technology that is 
available and adjust the requirements of the system to ensure success in development. 

Blanchard and Fabrycky present a generally well-accepted process that focuses on 
physical systems, but can also be applied to software systems. It is common for 
organizations to adapt the systems engineering process to their purposes. For example, 
the SMC systems engineering handbook describes the requirements generation process 
based on its own processes and procedures; however, it generally follows that of 
Blanchard and Fabrycky. 

Regarding software systems specifically, Rajat Sud (2003), in his thesis on 
software requirements generation, calls the process “requirements engineering” and 
though the language is slightly different, the purpose and mechanisms are generally the 
same. Sud, as described, and others such as Sidky (2002), explain that there are other 
tools and processes in problem definition that can be used to explore more fully the 
problem space. These tools such as fishbone diagrams or cause-effect diagrams help 
designers get to the root of what the customer views as their problem (Sidky et al. 2002). 

When it comes to the nature of requirements. Major General Greene (2003), a 
former Deputy for Acquisition and Systems Management (DASM), described that when a 
system is part of a system of systems, it is critical that requirements are developed from 
the top down to encourage an integrated view throughout development. With respect to 
program success and the importance of proper requirements, one GAO report indicates 
several senior leaders expressed concern that “systems engineering capabilities are 
generally lacking in the requirements development process,” and that that leads to 
requirements creep, cost over-runs, and schedule slip (GAO 2015). 

The report states that total system costs are typically not realized until after a 
systems engineering analysis is conducted. Prior to that, the high-level requirements only 
provide limited visibility into how the system will function and what the real cost and 
schedule will be. The GAO report also states “It is often at this point (after a systems 
engineering analysis)-when the technical specifications are finally understood and the 
design challenges are recognized—that cost and schedule increases materialize in a 
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program” (14). So, it is important to have that work done prior to committing to a budget 
and\ or timeline for development. 

In the case of LAWST, the documents that are examined in this literature review 
have a few purposes. First, the thesis examines the artifacts describing the development 
of LAWST and attempt to fit the development into an existing requirements generation 
model. Next, the processes that are presented in this literature will provide the framework 
for the methodology used to develop system requirements from a systems engineering 
standpoint. Both problem definition and a top-down approach are vital for creating 
requirements that are more integrated and complete. 

B. APPLICATION 

This chapter presents a number of different aspects of requirements. It articulates 
the importance of generating correct requirements using a systematic approach. It 
outlines the type of process that can be used to develop requirements. It also looks at the 
repercussions for not using a systems engineering approach prior to development. This 
information is the basis to support the methodology used for this study as articulated in 
Chapter III. 
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III. METHODOLOGY 


A. OVERALL STRATEGY FOR ADDRESSING RESEARCH QUESTIONS 

Our research begins with determining, from E20, how the requirements for 
LAWST were derived and developed. The second and parallel effort will be determining 
the system requirements based on an engineering approach. We will make a comparison 
between the two requirements sets to identify the differences and determine as to why 
those differences exist. 

LAWST will undergo an abbreviated systems analysis with the requirements 
generated from the systems engineering process and those requirements that were 
originally used to develop LAWST. This is in slight contrast to previous analysis where 
an attempt was made to derive system requirements from the actual performance of 
LAWST (Hall 2016). Normally, the goal of systems analysis is to determine the best 
system among a number of similar systems. In this case, the research will only evaluate 
LAWST capabilities against the system requirements to determine whether, and to what 
extent, LAWST meets the original requirements, as well as how it meets requirements 
developed using the systems engineering approach. We also identify any lost utility that 
was either not developed or not designed in LAWST. 

The research quantifies the differences in the development of the two sets of 
requirements. The problem definition, the purpose for which LAWST was developed, is 
used in developing a set of system requirements that describe a system that will address 
that problem. Ultimately this problem definition is the basis for the system. 

Determining what the requirements generation process was for the current version 
of LAWST is a straight-forward gathering of artifacts that led to the development of the 
tool. There should be relatively little synthesis of information to articulate what the 
process was, as this step is more of an investigation. The systems engineering approach to 
requirements generation will follow the process that was briefly described in Chapter II 
of this thesis. That is: problem definition, mission analysis, functional analysis. 
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performance requirements, and requirements trade-off. Finally, a framework will be 
presented for E20 to follow in developing requirements for future systems. 

B. DETERMINE ORIGINAL REQUIREMENTS 

There are a number of documents that are available that indicate the original 
method for requirements generation. The original intent behind the requirements that 
were used to develop LAWST must be considered to understand the context in which the 
requirements were generated. The research should show the detailed process used in the 
original requirements generation process and be supported by artifacts leading up to the 
development. 

C. REQUIREMENTS GENERATION 

I. Problem Definition 

The starting point for the systems engineering process is defining the customer’s 
problem. It may seem like an easy prospect to ask the customer what the problem is; 
however, the customer in many cases may not be able to articulate the problem clearly. It 
is often the case that customers begin to solve their problem by looking for a solution that 
may only partially address what they want to solve. They may also start by offering a 
solution before defining the problem. In those cases, customers approach an engineer to 
build a solution that they think they (the customers) want. This usually leads to wasted 
resources because the solution the customers wanted does necessarily not solve their 
problem. It follows that novice designers usually give the customer what they ask for 
rather than identifying, then delivering what the customer actually desires (Cross 2011). 
Designers spend a significant amount of time thinking about a problem, framing it in 
different ways, and trying to fully understand it. Without spending an appropriate effort 
on analyzing and understanding the problem, any solution may be inappropriate or 
incomplete. 

This research will begin with the primary customer for LAWST. The Marine 
Corps Expeditionary Energy Office was responsible for the development, through Group 
W, of the current version of LAWST. The primary mission of E20, based on its website 
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(http://www.hqmc.marines.mil/e2o/Mission-Vision) , is to improve the effectiveness of 
the Marine Corps by investing in ways to improve the energy consumption of combat 
systems and efficiency of the support structure on which Marine expeditionary forces 
rely. 

Since E20 is part of the Marine Corps and its mission and outcomes are nested 
within those of the Marine Corps, other sources that will help define the problem include 
future operational concepts for the Marine Corps, regulations and field manuals related to 
planning and wargames, and instructions and orders related to modeling and simulation. 

2. Mission Analysis 

The Analysis of a system’s mission explores the context of the system. The 
system will be used for some task that needs to be thoroughly explored. Questions that 
need to be answered here include: 

Who performs the task? 

Who else is involved in the task? 

Why is the task being done? 

Where will the system be used? 

What other systems will this one interact with? 

The comments from the stakeholder and documents that are explored as part of 
the problem definition are helpful in identifying the right questions to ask and point in the 
right direction for the answers. 

Considering the models for requirements generation from Chapter II, it is 
important to note the process is rarely sequential; in the course of researching the 
problem context, it might become necessary to revisit and revise the problem statement. 
In turn, revising the problem statement may also refocus the mission of the system and 
the tasks it must perform or enable. 

Some products from this phase may include a concept of operations (CONOP) 
statement and/or operational view diagram that defines how the system will be used. It is 
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also helpful to provide some link from the CONOP to the questions and answers in the 
mission analysis back to the problem statement. Diagram that shows the decomposition 
of the problem based on the mission context using a dendritic tool, like a fishbone 
diagram that shows the decomposition in some logical way can be helpful. These types of 
diagrams help provide the required traceability when the system requirements begin to 
emerge. 


3. Functional Analysis 

Functional analysis begins to add a layer of actions that the system must do to 
operate in a way that is consistent with the CONOP from the mission analysis. There are 
several tools that will be used in this analysis. Scenarios describe a system in action as it 
executes task that it was designed to do. Vignettes are short, detailed narratives that 
describe specific actions or sets of actions that the system completes in the scenario. 
Engineers can describe the vignettes in diagrams like a functional flow block diagram. 
Once all of the tasks that a system needs to perform in the scenario are described 
functionally, engineers organize like functions into groupings that begin to form a 
hierarchy that forms the functional decomposition of the system. 

A scenario provides additional context to the system that may not be apparent in 
the previous set of documents that are created as part of the mission analysis. The 
scenario provides information on the environment and begins to address the time scale in 
which that task must be performed. It also articulates interactions between operators and 
the system, the system and other systems and brings out information requirements that 
are transferred between each. Vignettes can not only fit into the overall scenario but also 
offer additional detail on critical tasks that the system must accomplish. 

Functional flow block diagrams (FFBDs) are a pictorial method of showing a 
scenario. They depict each element participating in the scenario and show the tasks that 
each of those elements performs. Additionally, they show the interactions between the 
operational elements, specify which tasks are dependent on others and the order of 
executing task, and estimate how long the tasks should take. 
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Once the scenario and vignettes have been mapped out in a FFBD, engineers 
capture the functions that the system performs, along with any inputs, outputs, control 
mechanisms, and resource requirements. 

4. Performance Requirements 

Requirements for a system do not need to be captured only after functional 
analysis of the system. At each step in the process, requirements begin to emerge. In the 
problem definition phase, requirements may appear in regulatory or statutory documents. 
The mission analysis may articulate environmental constraints in which the system must 
operate or times when the system will or will not be operational. These are all valid 
requirements. There is no agreed upon time or place in the process where requirements 
should be developed, but going through the process completely ensures the greatest 
exposure to potential requirements for the system. 

In relation to the functional analysis, every function can be mapped to a 
requirement, even if the requirement has a binary measure. In many cases, the additional 
information such as inputs and outputs, control mechanisms, resource requirements and 
timing will have more substantive requirements that can be measured in a quantitative 
way. There is a risk that more qualitative requirements may be interpreted in different 
ways causing confusion and conflict in later stages of development. Therefore, while it is 
not always possible to avoid them, it is advisable to make the effort to qualify the 
requirements with additional descriptions. 

Since LAWST is specifically designed to support logisticians in wargames, this 
section shows the specific linkages of the requirements back to the FFBDs, and in turn 
the scenarios that describe a wargame. The requirements also provide information on 
timing and interactions that the system has as the logistician moves through the planning 
and wargame process. 

5. Requirements Trade-off 

The requirements trade-off phase is the point in the systems engineering process 
when it begins to transition to more tangible, solution-oriented tasks for engineers. At this 
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point, physical components, blocks of code, schemes for training operators, adjustments 
to doctrine, and other Doctrine, Organization, Training, Materiel, Leadership/Education, 
Personnel, Facilities and Policy (DOTMLPF) considerations are fit together in different 
ways to explore the best combination of factors that meet the stakeholder’s needs. The 
measures of effectiveness (MOEs) and measures of performance (MOPs) that are used to 
evaluate the different alternatives should reflect the priorities and interests of the 
stakeholder. While the MOEs and MOPs can be developed by the engineer, they should 
be well understood and accepted by the stakeholders before any comparison of 
alternatives is done. 

This type of analysis is often called systems analysis (SA) and is often conducted 
by analysts who specialize in that discipline. Often a report is developed to inform a 
decision maker of the various feasible alternatives and explain which ones best address 
the problem for which the system is being developed. 

In the case of this research, EAWST, as the materiel solution, will be the only 
alternative that is evaluated. Additionally, this research will not take other DOTMEPF 
considerations into account and MOPs will be those that are described in the systems 
requirements developed up through the performance requirements phase. For each 
requirement, EAWST will be evaluated on whether it meets the requirement and to what 
extent. 

D. COMPARISON OF REQUIREMENTS 

It is important to determine the difference between the requirement sets developed 
with and without a systems engineering process. This step should be focused on the 
requirements from one set or the other that do not match or address, in any way, a 
requirement from the other set. This allows insight into the potential shortfalls or 
oversights in current requirements generation processes. On the other hand, there may be 
evidence that there are other factors that were not captured by a systems engineering 
process that may be important to the customer. 
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1. LAWST Compared to Original Requirements 

A majority of the work for this step has been completed by Dr. Steven Hall in 
2016 as part of an assessment of the readiness of LAWST to undergo a VV&A. That 
information will be reviewed during this step of the methodology. 

2. LAWST Compared to SE Developed Requirements 

This portion of the methodology will assess LAWST against each of the 
requirements developed during the requirements generation process using a systems 
engineering approach. Each requirement will have an explanation of how LAWST does 
or does not fulfill that requirement. LAWST will demonstrate the function described in 
the requirement or it will not. If LAWST does perform the required function, it should 
explain to what extent it fulfills the requirement. For any requirement in which it is not 
readily apparent that LAWST addresses it, there should be some method by which the 
requirement can be tested or determined. 

E. QUANTIFY DIFFERENT APPROACHES 

There is a resource cost associated with every aspect of system development. The 
differences in the approaches used to develop LAWST will be quantified to evaluate 
those costs. For the purposes of this research, the percent difference between the 
requirements sets may be used to make an estimate of the additional cost, if one exists, 
required to incorporate the additional requirements. A work breakdown structure, which 
useful in determining system costs, is also used in the analysis. 

F. DEVELOP FRAMEWORK FOR FUTURE DEVELOPMENT 

As a final element in this methodology, summarize the process used to generate 
requirements using the systems engineering process. This framework can be used with 
any generic system or software. This framework will provide a way for future systems to 
be developed with the most complete set of requirements to reduce future costs and 
development time in making changes to the first iteration of the system. 
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This methodology will allow the research to answer the primary research 
questions. It will determine how the original requirements for LAWST were developed, 
what the requirements for the system would be (had a systems engineering approach been 
used), and then determine if LAWST meets those requirements using an SE approach. 
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IV. COMPARATIVE ANALYSIS OF REQUIREMENTS 
GENERATION PROCESSES 


A. PRESUMED ORIGINAL LAWS! REQUIREMENTS 

The assessment of LAWST’s readiness to undergo a V&V process reveals that the 
requirements were neither included in the documentation describing the system, nor was 
there evidence of the process used to generate the requirements for the current version of 
LAWST (Hall 2016). However, in separate documents information on the “Expeditionary 
Force 21 (EF-21) Energy Study and Wargame,” which was conducted in early 2015 to 
examine the ability of the Marine Corps to support operations from an energy 
perspective, shows a modeling effort to determine if the anticipated fuel supply meets the 
demand of the units. The wargame document includes notes from the E20 director that 
indicate priorities for the effort (E20, unpublished document). A diagram from the 
document shown in Figure 6 indicates the origin of EAWST. 
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Expeditionary Energy Supply 
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h 


Figure 6. EF-21 Energy Study and Wargame Concept. Source: EF-21 Energy 

Study and Wargame document (E20, unpublished document) 


The block labeled “Directed Modelling Effort: Expeditionary Energy Supply,” in 
Figure 6 is what eventually becomes EAWST. Documentation that is provided with 
EAWST indicates that the Marine Air-Ground Task Force (MAGTF) Power and Energy 
Model (MPEM) is a basis for the demand and EAWST fills in the gaps with respect to 
the demand created by the logistics network itself. In addition, the document contains a 
set of questions found in Table 1. 
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Table 1. Study Questions from the EF-21 Energy Study and Wargame. 
Source: EE-21 Energy Study and Wargame document (E20, 
unpublished document). 


1 

What do the supply and demand curves look like from Sea-Echelon Area 
(SEA) to the FEOT? 

2 

Where are the CVs in the energy system? 

3 

How much fuel is required by type in each of the five zones? What is the 
capability to support in each zone? What are the risks by zone? 

4 

What is the demand of the various fuel types at various points in the 
operation? 

5 

What are the capacities to deliver and store fuel in each zone? Do they 
meet requirements? 

6 

What kind of USN/USMC C2 arrangements are necessary to assure fuel 
supplies? 

7 

How much fuel does it cost to deliver fuel at various points on the 
battlefield and as you alter battlefield conditions? 


The questions posed in the study and wargame concept are found in a later 
presentation in which they are mapped to a set of proposed requirements. Those 
requirements are listed in Table 2. 


Table 2. Eist of Requirements from the EE-21 Energy Study and Wargame 
Support Proposals. Source: Group W (unpublished document). 


The solution must: _ 

Calculate supply/demand by zone, echelon, or level _ 

Define throughput, storage, and delivery capability at each node or arc _ 

Calculate fuel consumed to deliver fuel _ 

Accommodate (two) fuel types and multiple types of delivery assets _ 

Accommodate other classes of supply _ 

5.1 Compete for delivery assets _ 

5.2 Deliver of other classes of supply consumes fuel _ 

Account for geographic separation of units/assets _ 

Allow for dynamic changes to the network (i.e., new nodes to support advancing forces, 
units changing location/fuel-resupply points, etc.) _ 


The presentation goes further and links the proposed requirements to the study 
question in Figure 7. 
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Requirements map to study questions 


y 

• Does supply meet demand? 

. R1 R2. R3. R4. R5.1.R5.2 

• What does the supply and demand curves look like from SEA to the PLOT? 

. R1.R4 

• Where are the CVs in the energy system?* 

. R1.R2. R4 R5 1.R. 6 

• How much fuel is required by type in each of the 5 zones? What is the 
capability to support each zone? What are the risks in each zone?* 

. R1. R2, R3 

• What is the stress against the various fuel types at various points in the 
operation? 

. R1. R4 R7 

• What are the capacities to deliver and store fuel in each zone? Do they meet 
requirements? 

R2, R5 1 

• What kind of USN/USMC C2 arrangements are necessary to assure fuel 
supplies?* 

• How much fuel does it cost to deliver fuel at various points on the battlefield 
and as you alter battlefield conditions? 

. R3. R6. R7 

5 


Figure 7. Linkage of Proposed Requirements to Study Questions. Source: EF- 
21 Energy Study and Wargame Support Proposals (Group W, 
unpublished document). 


This indicates that the system requirements that led to the development of 
EAWST originated primarily to support EP-21 Energy Study and Operational Reach 
Wargame. There is no description of the process used to decompose the study questions 
into any functions that a system must perform during its operation that provides the logic 
used to develop the requirements that the developer suggests. 

Additional information in the support proposal presentation indicates an initial 
feasibility analysis had different potential solutions (STORM Eite, Excel, ExtendSim, 
and Instantaneous Supply Calculator) (Group W, unpublished document). All were 
evaluated against the requirements to evaluate suitability and cost. The results of the 
analysis were not apparent in the presentation and there are no additional documents that 
indicate the further analysis exists. 
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B. REQUIREMENTS GENERATION FOR LAWST USING A SYSTEMS 

ENGINEERING APPROACH 

1. UAWST Problem Definition 

The problem definition is a mechanism by which the purpose for a system is 
established in order to begin the systems engineering process. 

E20 is the primary and priority stakeholder or customer for LAWST. E20 
indicated that it would like LAWST to be distributed as an aid in planning and 
wargaming at the tactical level. Since wargaming is an integral part of planning and 
evaluating courses of action (COAs), wargaming is always assumed part of the planning 
process. The E20 director, at the time of the development, also made hand-written 
comments on the EE-21 Energy Study and Operational Reach Wargame documents, 
which serve as an indication for the priorities of development. Group W points out an 
important element, with respect to tactical units, that logistics assets are shared among all 
classes of supply and any tool that is developed needs to include all of those classes. 
Additional comments add to the context of the problem: The Vision Statement says 
“efficient use of vital resources” (E20 2017, 1) and the Intent Statement further clarifies 
that the system should: “to change the way the Marine Corps employs energy and 
resources.” (E20 2017, 1). These statements and pieces of information went into crafting 
the problem definition: The U.S. Marine Corps does not have a robust tool to plan, 
analyze, and optimize logistics networks in support of Combined, Joint, and Interagency 
operations in a non-contiguous JO A against a range of non-hostile to hostile threats. 

2. System Mission Analysis 

The mission analysis is a critical step in the exploring the context of the problem. 
This system mission analysis is different from the mission analysis, or problem framing, 
that is described in later paragraphs. The system mission analysis, that is the focus of this 
section, is analyzing the mission and tasks that LAWST would perform as part of its 
operations in the environment in which it will operate. 

The Marine Corps Planning Process (MCPP) is articulated in MCWP 5-1 (US 
Marine Corps 2010). There are six basic steps in the process: Problem Eraming, Course 
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of Action (COA) Development, COA Wargaming, COA Comparison and Decision, 
Orders Development, and Transition. Problem Framing is a methodical analysis of a 
given mission; the specified and implied tasks that a unit must do, limitations, 
information requirements and other considerations that planners need to take into account 
when developing their own plans to accomplish their given mission. During COA 
development, the planning staff develops a number of distinct courses of action to 
address the given mission. COA Wargaming refers to evaluating each COA based on 
enemy action, branches and sequels at decision points and potential shortcomings. After 
each COA is evaluated, the staff weights each COA based on evaluation criteria 
developed prior to the wargame and based on the score of each COA, recommends a 
course of action to the commander during the COA Comparison and Decision. This step 
is followed by Orders development that entails the production of the orders for 
subordinate units. Orders include a detailed description of the course of action, 
coordinating instructions, logistics instructions, and command and control instructions. 
Transition generally goes through the dissemination of orders, back briefs, rehearsals, and 
other pre-mission tasks. This is a concise view of the planning process but provides an 
overview for reference. 

In the Problem Framing, there are a number of important pieces of information 
that a logistician must gather in preparation for the course of action development. The 
location of the mission is a critical starting point for gaining additional information about 
the situation. The logistician can determine existing infrastructure that could be used to 
support forward elements, initial estimates of throughput for major supply routes, initial 
distances and time required from sea bases, location of major logistics nodes, and current 
disposition of units and supplies. 

During the COA development phase the operations officer usually develops the 
scheme of maneuver for a specific COA and the logistician develops a complimentary 
logistics concept in support of that COA. The logistics concept should be as detailed as 
possible to support the COA Wargaming, Comparison and Decision. 

During the COA Wargaming, the logistician may be asked to provide his or her 

evaluation of a specific aspect of a COA with respect to the logistics concept, immediate 
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feedback is preferred based on short timelines for planning so, any information that 
logistician has needs to be readily accessible and interpreted. Information, as articulated 
in MCWP 5-1 should be granular to two levels down (i.e., if this is a battalion level plan, 
wargaming is typically conducted down to the platoon level). In addition, the logistician 
must be able to adapt to the wargaming method that the facilitator (usually the operations 
officer or executive officer) chooses: belt, avenue in depth, critical task or box method. 
The belt method refers to wargaming a COA within a specific set of times or phase lines. 
The avenue in depth method allows the facilitator to wargame a specific unit or task over 
the entire duration of an operation. The critical task or box method refers to examining 
specific times or places within each COA (US Marine Corps 2010). 

In the COA Comparison and Decision, the logistician needs to articulate the 
feasibility, strengths, and weaknesses of each COA with respect to the logistics concept. 
When evaluating a system, based on the tasks it needs to complete, the analysis should 
include an indication of how well the system should do any specific task. In the case of 
the MCPP, the best measures are based on extreme cases. For instance, the Rapid 
Response Planning Process dictates six hours to complete the planning process, allocating 
90 minutes total to complete Problem Framing, COA Development, COA Wargaming, 
and COA Comparison and Decision. This timing information is critical in articulating 
requirements that can support the MCPP. 

Systems Engineers use scenarios and vignettes in the mission analysis phase. The 
scenario is an overarching narrative that describes how the system will be used. In this 
case, the scenario is the MCPP. Vignettes describe, in more detail, specific tasks within 
the scenario. Two vignettes that are helpful in this case are the Problem Framing and the 
COA Wargaming that offer vital information on the type of tasks that a system must 
support. 

Designers sometimes use a mind-map to link the different aspects of the mission 
analysis for a better understanding of the logistics tasks as part of the MCPP. Mind¬ 
mapping allows designers to expand on topics, examine linkages between items, and 
group ideas together to organize their work. Figure 8 was created in an application hosted 
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on mindmapmaker.org called “Mindmaps” and shows one specific branch of a mind-map 
related to wargaming a COA. 



Figure 8. Mind-map Related to Conducting Wargame on a COA. 


This portion of the mind-map examines COA wargaming. It organizes the 
methods of wargaming and the different considerations that need to be taken into account 
when a wargame is conducted. For instance, Figure 8 shows the wargame and branches 
describing different aspects and considerations of a wargame: the method, the enemy, 
evaluating two levels down, action-reaction-counteraction. This type of tool allows a 
large number of related or unrelated tasks to be quickly captured and organized for better 
visualization of the tasks involved with this system. A full mind-map for this mission 
analysis can be found in Appendix A. 

This mission analysis provides a structure leading into the functional analysis. It 
provides some top-level functions that the system must do in performing the tasks during 
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the mission and provides additional detail to an otherwise arbitrary selection of functions 
that the system will perform. 

3. Functional Analysis 

The functional analysis step in the SE process is really the beginning of looking at 
the system that will address the problem defined in the problem definition, but within the 
context of the tasks outlined in the mission analysis. The system, at this point, should be 
defined by the functions that it needs to do. Those functions should complement and 
assist the planners, from the scenarios in the mission analysis step, in accomplishing the 
tasks that are described in the scenarios. 

At a top-level view, the system can be bounded by the tasks that describe its use. 
In this case, logisticians need to begin analysis by creating concepts or plans to support 
COAs developed during the COA development phase of the MCPP. Once an analysis of 
the COAs is complete, the system has completed its tasks. The comparison and decision 
of which COA to use is based on criteria that the logistician may not have any control 
over; however, the commander deciding which COA to execute will take the logistician’s 
recommendations into consideration when making the decision. Figure 9 shows the high- 
level functional decomposition of a system that supports a logistician in analyzing a 
COA. 



Figure 9. Top Fevel Functional Decomposition of an Analysis Tool. 
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Additionally, Figure 10 shows those functions in the sequence they need to occur, 
usually called a functional flow block diagram (FFBD), in order to support CO A 
Wargaming. 
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Figure 10. Functional Flow Block Diagram of a Wargame Analysis Tool. 

In Figure 9 and Figure 10, the F.O function. Create COAs, and the F.999, COA 
Comparison are the starting and ending points for the system. F.l, F.2, and F.3 are the 
primary focus points for this tool, and presumably LAWST. 

Each function can be further broken down to look at more specific aspects of the 
system as it relates to lesser tasks. These tasks, at a detailed level, are one source of 
system requirements that are recorded during the requirements generation phase. For 
example, F.l, Prepare for COA Wargame can be broken down by looking at all the tasks 
that different entities have to perform while preparing for a COA wargame. Figure 11 
shows an FFBD in which the S4, the logistician, is using the tool/system to accomplish 
the tasks necessary to prepare for a wargame. 
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This is the beginning of the FFBD describing the logistician preparing for a COA wargame; the 
entire diagram can be found in Appendix A. 

Figure 11. FFBD of a Logistician Using a Support Aid/Tool While Preparing 

for a COA Wargame. 


The FFBD in Figure 11 includes the players or nodes in the task, the information 

that is transferred between nodes, and the sequence of events that each node must 

complete to accomplish the task. For this FFBD, there is an S4, the system on which he 

or she is working, data that the system needs to contain, and external systems that 

interact. This FFBD describes the following vignette from the System Mission Analysis: 

The S4 selects the map sets needed for the operations area where the mission will 
take place by entering an eight or ten-digit grid location. The system loads a set of 
maps, including digital terrain elevation data (DTED), hydrology, imagery, and 
standard MGRS map sets. The S4 either imports COA graphics from an external 
system or creates the COA graphics on the tool. The S4 then determines the 
usable routes or arcs that a logistics network could use to support the COA. The 
S4 also inputs friendly unit information, logistics asset information, supply 
locations. The S4 sets parameters for each one, including desired days of supply 
(DOS), supply capacity limits, and demand. The S4 then creates a logistics 
concept to support the COA and task organizes logistics assets to support the 
COA. 
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Another factor to consider is the timing of the functions. The MCPP allocates 
about 20 minutes during a planning cycle, in support of operations, to developing COAs. 
Assuming three COAs are developed, a hypothetical allocation of time for each task is as 
follows: 

• Select Map, 10 seconds 

• Input COA graphics, 40 seconds per COA 

• Input usable routes, 40 seconds per COA 

• Input friendly unit locations, 40 seconds per COA 

• Input friendly asset information, 40 seconds per COA 

• Input friendly supply information, 40 seconds per COA 

• Build task organization, 40 seconds per COA 

• Input desired DOS, 10 seconds per COA 

• Input capacity limits, 10 seconds per COA 

• Input friendly demand, 10 seconds per COA 

• Create Concept for logistics support, 180 seconds per COA 

These times can be allocated in other ways based on how the customer wants to 
trade-off different capabilities of the tool. This initial allocation can be adjusted in 
subsequent iterations of a requirements generation process. Figure 12 shows a snapshot 
of this set of tasks associated with preparing for a wargame and their timing. 
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CORE has a simulation mechanism that allows the timing to be shown pictorially for greater 
understanding of the functions over time. 


Figure 12. Simulated Times for Eaeh Task in an FFBD Created in CORE. 


In this figure, the times combine to 1200 seconds, or 20 minutes, which is the 
time allocated by the MCPP to generate COAs in a rapid response planning timeline. 

A complete set of EEBDs and functional hierarchy is found in the Appendix A. 

4. System Requirements 

System requirements come from a variety of sources. However, all requirements 
should have the same general properties. Karl Wiegers (1999), writing on software 
requirements states they should be: 

Correct; a robust process with feedback loops will ensure correct 
requirements 

Eeasible; requirements should be attainable with the resources provided by 
the customer. 

Necessary; they should be traceable back to the original problem 
statement. 

Prioritized; developers should understand the requirements that are the 
most important for success. 

Unambiguous; wording should be clearly understood by different 
designers in the same way. 

Verifiable; there should be a way to measure or confirm that a requirement 
has been met. 
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Other aspects of requirements described by Buede (2009) include: complete, 
consistent, correct. He also stresses the need for requirements to focus on defining the 
problem to be solved rather than the solution. 

The primary source of requirements is from the functional analysis. An initial set 
of requirements is taken directly from the functions on a one-for-one basis. Care is taken 
to eliminate redundant requirements and correct inconsistent requirements. 

The first function that will lead to a requirement is “Query data for maps of 
selected area.” An operator should be able to enter a grid coordinate somewhere in the 
area of operations and find all the associated maps with that location. Because the 
operator may be operating on a ship and a potentially secure network, the maps should be 
readily accessible. There are other command and control, intelligence, and fires systems 
that also use maps. Using a standard mapping engine that already accepts those types of 
maps reduces the need to keep all map sets resident on the system. The requirement could 
then be written as: 

“The system shall use a mapping engine that accepts CADRG (MIL-C-89038), 
CIB (MIL-STD-2411) and DTED map data.” 

This requirement is correct: logistics networks are visualized on a map, as are 
COA graphics and both are determined during the mission analysis phase. The 
requirement is feasible: there are several open source map engines that are compatible 
with standard maps sets used by the military. The requirement is necessary: it traces back 
to specific functions and tasks in the mission analysis phase. The requirement should be 
prioritized as high priority: maps are a basis for many types of planning and wargaming. 
The requirement is clearly-worded. The requirement is verifiable; a demonstration could 
determine whether the requirement has been met. This is an acceptable requirement. 

A related requirement is: 

“The system shall allow operators to select the map, and display it at a scale 
necessary for planning, and location within 10 seconds.” 
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While the time limitation seems arbitrary, it is necessary in maintaining the 
timeline required by a rapid response planning process as described in Figure 12. If other 
times during the COA development phase of the MCPP could be reduced, then longer 
times to locate the appropriate maps may be acceptable. This is a good example of a 
requirement that can be negotiated with the customer. For many of the same reasons as 
the previous requirement, this requirement is also acceptable. 

As related to wargaming specifically: 

“The system shall allow operators to input branches and sequels identified at each 
decision point during the wargame.” 

Almost every version of wargaming involves decision points and branches. The 
tool needs to be able to accommodate this common mechanism in order to be useful to 
logisticians participating in a wargame. 

Other requirements may come directly from the customer. For example, E20 is an 
organization that is focused on energy efficiency so a required element is the total amount 
of fuel used and the rate at which it used for any given COA. That required element 
manifests itself in the following requirement: 

“The system shall determine the overall fuel used, over time, for each COA.” 

By examining the customer needs, mission tasks, and required functions designers 
can determine the requirements for a system. However, other sources of requirements are 
often overlooked such as regulatory requirements and requirements that are derived from 
best business practices. 

Regulatory requirements are often roadblocks to successfully operating a system 
in its intended environment. For example, the logistics tool will operate on the Navy 
Marine Corps Intranet (NMCI). In order to operate on the NMCI, the tool must comply 
with all the applicable rules, guidance, and certifications that govern the network as per 
the DON CIO Memo 02-10, 26 April 2010: “The system shall be compliant with all DoN 
regulations for authority to operate (ATO) on NMCI networks.” 
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A complete set of requirements developed during this research is found in 
Appendix B. 

5. The Extent That LAWST Fulfills the Presumed Original 
Requirements 

Section A in this chapter introduces the potential origins of requirements for 
LAWST. Half of these assumed requirements are met by LAWST and can be verified by 
inspection. For Requirement 1, LAWST can calculate supply and demand by echelon and 
level. However, the term zone is not defined and there does not seem to be a clear way to 
calculate supply and demand within a specified portion of the supply network using 
LAWST. 

Requirements 2 and 6 seem straightforward and can be readily demonstrated 
using LAWST but the word “define” seems targeted to LAWST. Since LAWST is 
described in the LAWST documentation as a data driven model, it is actually the operator 
that defines the throughput, storage and delivery capability so the requirements are 
unclear. 

Requirement 3 is closely related to requirement 5.2 in that it specifies the need to 
determine the fuel consumption for a specific commodity. The difficulty is that LAWST 
does not specifically break out the fuel cost of any given commodity type. While the 
commodity fuel cost for any given commodity type could be determined artificially by 
only including the demand of that commodity in the model, LAWST does not break out 
fuel cost of any given commodity. 

LAWST does not show any feature that accounts for different types of fuel as 
specified in requirement 4. While artificialities could be incorporated such as defining a 
commodity as a second fuel type with a specific demand for a unit, LAWST does not 
inherently accommodate two fuel types. 

The final requirement is supported by LAWST. Concepts that the LAWST 
documentation puts forward such as Scripted sorties can be included to change the 
baseline logistics network at certain times and places. 
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An overall assessment of LAWST against these articulated requirements is shown 
in Table 3. 


Table 3. Summary of LAWST Assessed Against Articulated Requirements 


Requirement 

Degree that LAWST meets requirement 

Requirement 1 

Partially 

Requirement 2 

Yes 

Requirement 3 

Partially 

Requirement 4 

No 

Requirement 5.1 

Yes 

Requirement 5.2 

Partially 

Requirement 6 

Yes 

Requirement 7 

Yes 


In summary, LAWST fulfills 4/8 of these requirements, partially addresses 3/8 
requirements, and does not address one requirement. 

If these requirements were the correct requirements to which LAWST was 
developed, then LAWST failed to meet all the requirements and may not be suitable for 
its intended purpose. It may be that these are only an initial set of requirements and 
additional trade-offs were made prior to developing the system. However, without a 
record of those negotiations and the outcomes, there is no conclusive answer to whether 
LAWST is valid for the purpose that these requirements stem from. 

6. The Extent That LAWST Fulfills Requirements Generated by a 
Systems Engineering Approach 

There are 45 potential requirements developed using a systems engineering 
approach. Appendix B contains an assessment of how well the current version of 
LAWST meets the requirements that were developed using a systems engineering 
approach. In the interest of brevity, this section will examine a sample of the full set of 
requirements. It presents a summary for how the current version of LAWST fares with 
the requirements that were developed using a systems engineering approach. The 
following, selected randomly, are examples of the assessments: 
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Requirement two states “The system shall allow operators to select the 
appropriate map and location within 10 seconds.” LAWST requires operators to upload a 
picture of a map and size it correctly to the grid system in the user interface by matching 
the corners of the picture to a latitude/longitude point. This process takes a few minutes 
to accomplish and is far from the 10 seconds described in the requirement. 

Requirement eight states “The system shall allow operators to set objective DOS 
for friendly units.” LAWST has a function that allows operators to adjust the required 
DOS for units and logistics nodes. 

Requirement 16 states, “The system shall allow the creation of arcs/routes for the 
supply network within 40 seconds.” LAWST allows nodes and arcs to be created and 
placed on the map. There are two ways to do this, first by manually creating the node or 
arc. Nodes are can be placed on the map by clicking on the point on the map or entering a 
latitude or longitude. Arcs are defined between two different nodes. The second way to 
produce the nodes and arcs is to define them all in a Microsoft Excel spreadsheet and 
adjust the configuration file to call that spreadsheet. This requirement can be met 
depending on the situation. If the nodes and arcs are pre-defined and readily available in 
an Excel file, in the proper format, EAWST can meet this requirement. If the nodes and 
arcs must be manually entered, this can take on the order of minutes to hours depending 
on the complexity of the network. In this case, EAWST would not meet the requirement. 

Requirement 23 states “The system shall allow operators to evaluate the state of 
the logistics networks at each branch and sequel of an operation.” EAWST allows one 
network at a time to be evaluated. Additional branches and sequels would need to be 
evaluated as separate networks. This could be accomplished by adjusting the nodes, arcs, 
unit locations, and other relevant portions of the network and re-evaluating. Re-adjusting 
elements in the network may take several minutes and not be useful within the time 
constraints of a fast-paced wargame. In the case of a rapid response planning process, the 
wargame of a single COA may only take about five minutes. While EAWST can evaluate 
different networks, comparing a network with several branches and sequels is infeasible 
for the software: EAWST would not meet this requirement. 
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Requirement 31 states, “The system shall determine the number of excess 
transportation assets within the logistics network over time.” LAWST can determine the 
utilization rate of transportation assets at a logistics node. This is a derivative piece of 
information based on the number of assets being used over a period of time. With 
relatively little effort, a logistician can determine where in the network there are available 
transportation assets; therefore, LAWST fulfills this requirement. 

Overall, the current version of LAWST meets 24/45 requirements that were 
developed using a systems engineering approach. The remaining requirements would not 
be achieved by LAWST without substantial investment of additional time, money, and 
effort. 


C. COMPARE THE REQUIREMENTS SETS 

There are several differences between the requirements sets, namely the number 
and detail of requirements, the traceability of the requirements, and the type of 
requirements. The larger number of requirements is typically due to a clearer 
understanding of the functions that the system must perform. Traceability means that the 
requirement has a reason that supports the analysis in a previous step of the design 
process. The different types of requirements usually stem from different viewpoints being 
evaluated as part of a design process. 

The original seven LAWST requirements stemmed from the need to analyze a 
specific event, the EF-21 Energy Study and Operational Reach Wargame. The 
requirements are focused on answering the questions that the study aimed to answer, 
which is reasonable, if the tool is meant only to be valid for the specific wargame. On the 
other hand, if the tool was meant to address EF-21 Energy studies beyond the wargame, 
additional information should have been considered during development. With a systems 
engineering approach, the problem is analyzed with a more rigorous stakeholder analysis 
that uncovers additional uses for the system beyond the short-term problem. The 
expanded problem set uncovers additional uses and required functions that need to be 
accounted. Thus, the SE-developed requirements are more thorough in addressing the 
aspects of the system that the customer desires. 
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The traceability of the requirements is an important aspect of any system 
requirement. It ensures that system specifications will produce a capability that can 
address the problem for which it was designed. The assumed original requirements 
provided by Group W included a linkage between each of the requirements and a specific 
question asked in the EF-21 Energy Study and Operational Reach Wargame concept. 
This indicates that a system developed to this requirement set would be valid for 
participating in Operational Reach or any other application with the same limited scope. 
The requirements developed through a systems engineering approach have traceability 
that is examined through operational planning and wargaming procedures, as well as a 
wider scope of questions that would specify a system that is useful for a larger range of 
applications and uses. 

The types of requirements that are developed using these two approaches are 
significantly different. With the original requirements set, the focus of the requirements is 
mainly on construction of the logistics network, what factors an operator needs to control, 
and how to analyze the data. These requirements were tailored to support a single 
seminar wargame that did not require immediate results. The systems engineering 
approach developed additional types of requirements. Usability requirements, not 
addressed with the original system requirements, addressed the time constraints that 
operators had to work in when they are participating in a planning process. The systems 
engineering approach also uncovered interoperability requirements based on the 
environment within which the system would be operating. Additionally, the stakeholder 
analysis produced the need for a system to help operators identify ways to adjust the 
logistics network to overcome problems that arise during the construction of the network 
or the wargame. 

The systems engineering approach produces requirements that not only address 
the customers immediate issues but also get to the root of the problem that the customer 
has. It produces requirements that address a larger range of capabilities that a system 
needs to have, and by more thoroughly analyzing the problem, produces a more robust 
system than would otherwise be realized. 


41 



An additional insight here is that there are no requirements oriented to operations 
at a tactical or operational level in the presumed original requirements so therefore, the 
problem that drove the original requirements is not the one stated in the problem 
definition (from the SE approach). In other words, the problem that E20 wants EAWST 
to address is not the problem that it was developed to address. 

D. QUANTIFYING DIFFERENCES IN APPROACHES 

We use two methods to quantify the approaches: work breakdown structure and 
value tree. A work break down structure shows the resource requirements for individual 
parts of a system as they are related to the total development of the system. An objectives 
tree reflects the interests that a stakeholder has in developing a system. 

There are some difficulties for quantifying the differences in the processes that 
produced the two requirement sets. To begin with, the problem statements that produced 
the two sets of requirements are potentially different since there is no documented 
version of the problem statement for the original version of EAWST. The only viable 
process available to us for this analysis is the systems engineering approach. There is no 
one-for-one mapping between requirements from the two sets. Additionally, each 
requirement has a different level of effort associated, with respect to the resources 
required to realize it in a system. The following analysis recognizes these issues and for 
the sake of discussion makes the following assumptions: 

• There are five types of requirements that can be discerned; usability, 
model/simulation, analysis, interoperability, and optimization. 

• Each requirement, within a set of requirements, needs the same level of 
effort to incorporate into a system. No weighting is applied to any one 
type of requirement. 

• The requirements lists are complete. That is, the list is agreed upon by 
both the customer and developer. 

• The model/simulation level of effort between the two requirements sets 
will be the same level of effort in order to compare the sets. 

• A work breakdown structure (WBS) will be used to compare the 
requirements sets 
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Consider the level of effort for the first set of requirements to be 100 hours of 
work to realize System A using the eight requirements listed in Section C of this chapter. 
Half of the work is done on model/simulation requirements and the other half is on 
analysis requirements so a WBS for this system would look as shown in Figure 13. 



Figure 13. Notional WBS for System A. 


Now consider a system, System B, developed against the set of requirements 
generated using a system engineering process and as seen in Figure 14. Here the 45 
requirements are organized into five categories: six requirements are usability 
requirements, three are interoperability, 18 are related to model/simulation, 16 are 
analysis, and two are optimization. 



Figure 14. Notional WBS for System B Developed Using a Systems 

Engineering Approach. 


Recall the assumption that the model/simulation level of effort between the two 

systems would be proportional. Then with System B, keeping the model/simulation effort 

proportional to that in System A, then takes 125 hours to complete. The general insight is 

that a system developed using a systems engineering approach will take more time to 

develop when compared to an undirected requirements development process. 
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Now, recall the extent to which LAWST meets the requirements developed using 
a systems engineering approach. If partially met requirements only count as one-half of a 
met requirement, then LAWST achieved 28.5 requirements of 45 requirements or 63%, 
leaving 37% of requirements unmet. If LAWST was developed in 100 hours as in System 
A and only fulfills 63% of the requirements, then the rework required to meet the rest of 
the 37% of the requirements is about 58 more hours. This brings the total number of 
hours for System A to meet the requirements for System B to about 158 hours. 

The point here is that a system developed against a set of SE requirements may 
appear to be more expensive to produce. However, if a system is not produced using a 
systems engineering approach and requires rework to meet that set of requirements, it 
will be more expensive, in terms of level of effort, in the end. 

The numbers presented here provide anecdotal evidence of the increased cost 
when not using a systems engineering process that reflects a 58% increase in recourse 
requirements. GAO reports that actual program cost increases due to changing 
requirements have been anywhere between 23%-114% of initial cost baselines (GAO 
2015). The result from this analysis is within the range of the GAO reports. 

Another way to look at the different approaches to requirements generation is by 
looking at an objectives tree for the customer, E20, and compare it to the requirements 
sets and determine to what extent the different approaches support E20’s objectives. In 
the Problem Definition phase of the systems engineering process, the research explored 
high-level interests of E20, specifically around the efficient use of resources and 
influencing the way the Marine Corps employs its energy and resources during 
operations. When it comes to efficient use of resources, analysis and optimization are key 
aspects of addressing that objective. Eikewise, interoperability and usability are key 
aspects of getting tools to Marines at the lowest level where they can be easily employed 
and affect change in the way they think about and use energy and other resources. 
Another broader category of objectives would be to provide general information and tools 
to the Marine Corps in managing the complex issues around managing energy and 
resources. E20 concurred with the following weights in Table 4. 
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Table 4. Weighting for the Categories of Requirements and Factors Related 

to E20 Objectives. 


Eactor 

Weight 

Analysis 

0.25 

Optimization 

0.15 

Interoperability 

0.1 

Usability 

0.2 

Model/Simulation 

0.3 

Total 

1 


A reasonable objectives tree with weighting for this organization is in Figure 15: 



Figure 15. Objectives Tree for E20. 


The factors organized under the organization’s objectives add to 100%, for 
example, the objective “Efficient use of resources” has two factors: Analysis and 
Optimization. While the weights of the factors are 0.25 and 0.15 respectively, their 
relative weights, 0.625 and 0.375 add to 1 or make up 100% of the factors for “Efficient 
use of resources.” Now, if the different approaches to requirements generation are 
compared in this way, the requirements developed using a systems engineering approach 
address all the objectives of the organization where the assumed original requirements 
only address 55% of the organizations objectives. The shortfalls of the assumed original 
requirements being a tool that is interoperable and usable at the lowest levels and the 
ability to optimize the use of resources. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. SUMMARY OF RESULTS AND INSIGHTS 

The methodology described in chapter III outlines a process by which the process 
that was used to develop systems requirements for LAWST is compared to a systems 
engineering process for developing system requirements. Since LAWST is a system that 
has already been developed and used by E20 in evaluating energy distribution, the 
evaluation of the current requirements and the process by which they were developed is 
primarily an investigation of current documentation regarding the system. 

LAWST is a useful tool for seminar wargames such as the EF-21 Energy Study 
and Operational Reach Wargame. It was designed to complement MPEM’s operational 
unit energy demand with the demand produced by the logistics network used to deliver 
those energy resources. The results provide an estimate of risk and give some indication 
as to where problems in the logistics network may be. Outside the scope of this specific 
seminar wargame, the system has limited utility since it is not designed with a larger 
scope. 

EAWST is insufficient at the tactical level, battalion and brigade, for planning and 
evaluating logistics networks. The primary reason for this is its inability to support the 
timelines required to build COAs, wargame, and evaluate those COAs. In cases such as a 
rapid response planning process, there are only 4 hours between the receipt of a mission 
and the distribution of orders. EAWST is designed for overnight analysis of a logistics 
network and cannot support such planning. 

System requirements developed using a systems engineering method start with a 
problem definition based on E20 comments and documentation. The problem is further 
refined by including the context of the mission in, which the system will be involved. 
This additional specification differs from the original process that drove the current 
version of EAWST in that it includes the system’s use at the tactical and operational 
level. A functional analysis breaks down the functions of the system which leads to 
system requirements. Those system requirements developed using a systems engineering 
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approach show a distinct difference to the original requirements in that they have 
additional emphasis on interoperability, usability and optimization type requirements. A 
brief analysis of LAWST indicates that the system meets 24 of the 45 requirements. 

The research shows, using LAWST as an example, which the costs for changing 
the system after it has been developed are greater than if the system were developed 
correctly in the first place. Additionally, supporting data from GAO indicates program 
costs increasing over 100% of initial costs because of changes to requirements (GAO 
2015). This supports the need for a systems engineering approach to developing systems, 
especially earlier in the process prior in examining the problem and developing 
requirements. 

B. CONCLUSIONS 

There are a number of questions that this research answers: 

1. How Were the Design Requirements Established for the Development 
of LAWST? 

There is evidence in Chapter IV, Section A, which was provided by E20 and 
Group W, which shows a directed modeling effort, in parallel with MPEM that will 
support a wargame and study. Additionally, Group W provided a presentation that 
outlines the proposed support for the EE-21 Energy Study and Operational Reach 
Wargame (Group W, unpublished document). In that presentation, the questions posed in 
Operational Reach are directly linked to proposed solution requirements that are 
evaluated in Chapter IV, Section C. It follows that this is how the design requirements 
were established for the development of EAWST. If this is indeed the case, an assertion 
can be made that EAWST could be valid as a tool to assist analysts, during a deliberate 
seminar type wargame, in evaluating the energy consumption of the logistics network, 
while delivering supplies to maneuver units whose energy demand is modeled through 
MPEM. This assumes that the model can be verified to be correct within some defined 
tolerance against empirical data. Outside of that scope, there is little evidence that 
EAWST would be valid. 
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2. What Would the System Requirements for LAWST Be if a Systems 
Engineering Approach Had Been Used? 

This research begins by defining the problem. Information from E20 indicates 
that the organization is interested in improving the way the Marine Corps supports 
operations from a perspective of energy efficiency. This is partly accomplished by 
equipping Marines with tools geared towards operating in a more expeditionary manner. 
It seems that the original requirements did not capture the need to use LAWST in a 
tactical or operational environment and, therefore, did not accommodate the type of 
functions and usability features that are necessary at that level. 

The systems engineering method for requirements generation stresses starting 
with the proper question and understanding the environment in which the system will 
operate. In the case of LAWST, wargaming in the context of planning for a mission in a 
time constrained environment is significantly different from a wargame conducted as part 
of a study conducted over several weeks Blanchard and Labrycky (2011) state that the 
application of systems engineering can “ help promote greater design maturity earlier.” (p 
64) The systems engineering method for requirements generation produces a larger 
variety of requirements because of the greater scope of viewpoints that are examined. 
Adding further support: “Without sufficient systems engineering input to better define 
requirements and examine trade-offs early on, there is no assurance that acquisition 
programs going forward have a sound basis to start system development.” (GAO 2015, 
20) The requirements developed for this research along with a brief explanation of each is 
found in Appendix B. 

3. Does the Current Version of LAWST Address the System 
Requirements That Would Have Been Developed through a Systems 
Engineering Approach? 

The Logistics Analysis and Wargame Support Tool, if evaluated, would most 
likely meet a majority of the requirements in Appendix B. There are two primary 
shortfalls with the current version of LAWST, as it relates to requirements developed 
using a systems engineering approach: usability and interoperability. 
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Usability is generally a function of how easy the system is to use. The drivers for 
usability can come from two places: the mission that the system must participate in and 
other factors like amount of training. In this case, the amount of training was not taken 
into account with this specific iteration of the systems engineering method; however, a 
majority of the usability requirements are produced specifically because of the mission 
that the system will be used for. If LAWST is to be used to evaluate a logistics network 
as part of a planning process, the ease of use and the speed at which operators can use the 
tool is critical. 

Interoperability is important because of the environment within which the system 
operates and the tasks that it must perform. From the mission analysis, LAWST would 
operate in a tactical environment and need to interact with other systems used for 
planning operations. It would be required to operate on the same network where other 
planning tools are being used and need to both share and provide data to those systems. 
LAWST was designed as a stand-alone system so these aspects have not been addressed. 

The requirements that supposedly drove the design of LAWST are not 
specifically traced to any problem or gap that the system is addressing. Documentation 
from E20 shows linkage between requirements and questions from Operational Reach; 
however, there is no other evidence of verbal or written linkage to any problem. 
Establishing validity of the model is impossible without linking it back to the problem 
that EAWST was designed to address. 

EAWST does not meet E20 system objectives. EAWST is not postured to meet 
the demands of VV&A because there is little documentation on the process used in 
designing the system. Eurthermore, the E20 requirements development provides an 
inadequate foundation for valid improvements to EAWST or as a means to assess the 
degree EAWST meets E20 needs. 
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c. 


RECOMMENDATIONS 


1. Framework for Future Development 

E20 should adopt a method to guide future development, in order to reduce time 
necessary to deliver capabilities to the field, reduce resources necessary for development, 
and produce more positive outcomes in early deliverables. We recommend that the 
systems engineering process guide those future developments. Incorporating such a 
process increases the likelihood of delivering products that are more immediately useful 
to the goals of E20. 

A simple process, similar to that used in this research, that E20 can use in 
generating requirements can be found in Eigure 16 and explained in the following 
narrative: 


Systems Engineering 
Method for Requirements 
Generation 



Mission/Context 

Analysis 


Functional 

Analysis 

Performance 

Requirements 

Requirements 

Trade-off 

System 

Requirements 


Eigure 16. Model for Requirements Generation Using a Systems Engineering 

Approach. 
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This model is a simple graphic that describes how to develop system requirements 
using a systems engineering approach. 

• Step 1, Problem Definition: Determine what the problem or gap that the 
system is addressing. Get to the root of why the system is being developed 
by talking to relevant stakeholders and examining related topics. 

• Step 2, Mission Analysis: Determine where the system will be used, how 
it will interact with operators, other systems, and its environment. 
Determine the tasks that the system will be used for, what information is 
needed to conduct the task, what information the system must provide or 
action that the system must complete as part of its operation in completing 
the task. Describe the timing of the task, is it time dependent; near real 
time, is timing prescribed, or does time not matter. Determine the system 
operator, level of training, knowledge of the task being conducted, or 
physical limitations. 

• Step 3, Functional Analysis: Determine the functions of the system; what 
actions the system must complete as part of its operation. Use information 
from the mission analysis to support the functional analysis to ensure 
proper traceability. 

• Step 4, Performance Requirements: Determine a set of requirements that 
can be communicated to a developer to design the system. The 
requirements should be focused on the functions that the system must 
perform as part of its operation. Capture both functional requirements as 
related to the functional analysis and non-functional requirements that are 
related to other aspects as described in the mission analysis. 

• Step 5, Requirements Trade-off: Determine the time and resources 
available to develop the system and make necessary trade-offs to system 
capability. This may require re-examining the problem definition, mission 
analysis, and functional analysis to get the right balance of capability for 
resources available. 

2. Future Work 

E20 has expressed interest in validating LAWST for use by the Marine Corps. 
The scope for what uses LAWST could be valid is somewhat limited by how it was 
designed, as well as the actual tasks that it can perform. If the desire is to use the tool as 
an aid in planning and analyzing logistics networks at the tactical level, additional 
considerations such as interoperability and usability should be taken into account for 
further development. The additional capabilities that LAWST may require should be 
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carefully considered when determining if the system should be significantly changed (i.e., 
new development) to address the capability or the system should be moderately changed 
(i.e., new interface or built in tools) to rectify the shortcomings. A deliberate analysis 
should be conducted to determine the best way to address this, in many cases it may seem 
easier to adjust existing systems rather than starting from the beginning but this may turn 
out to have a much larger resource impact than anticipated (Blanchard 2011). 

There are also additional areas to explore in relation to LAWST. LAWST relies 
on energy usage data from MPEM. Perhaps other areas where LAWST makes 
assumptions to simplify the analysis such as resupply scheduling could also be 
incorporated. For instance, in an in-process review to E20 in April 2017, one project 
introduced the concept of “Scheduling Ship to Shore Fuel Deliveries”; this area is one 
that LAWST assumes certain information which may or may not be there. LAWST 
assumes that, at a logistics node, there is a pool of available vehicles with an available 
amount of time and capacity. As long as the availability is met, LAWST does not 
explicitly define which assets deliver which supplies. E20 should use this type of tool to 
evaluate the assumptions made in the development of LAWST. 
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APPENDIX A. SYSTEM ENGINEERING ARTIEACTS 


A. MIND-MAP FOR TOPICS RELATED TO LOGISTICS 
NETWORKS 



I Logistics Networks j 



I Optimize (locally optimized?) i 
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APPENDIX B. REQUIREMENTS EROM A SYSTEMS 
ENGINEERING PROCESS 


1. The system shall use a mapping engine that accepts CADRG (MIL-C- 
89038), CIB (MIL-STD-2411) and DTED map data. 

This requirement is linked to the requirements analysis and is related to a 
planning scenario where the logistics tool may be located on a secure network with 
limited access to commercial maps. Standard mapping engines will accommodate readily 
available military maps and DTED. 

EAWST meet this requirement. 

2. The system shall allow operators to select the map, and display it at a scale 
necessary for planning, and location within 10 seconds. 

This requirement is based on the time constraints related to creating the support 
concepts for three COAs in a 20-minute timeframe. 

EAWST meet this requirement. 

3. The system shall allow operators to define non-standard friendly assets. 
Requirement based on mission analysis and potential task that an S4 must 

execute. 

EAWST me^sj this requirement. 

4. The system shall allow operators to define non-standard supply types. 
Requirement based on mission analysis and potential task that an S4 must 

execute. 


EAWST toeetsi this requirement. 

5. The system shall allow operators to create a task organization based on 
available friendly units and assets within 40 seconds. 

This requirement is based on the time constraints related to creating the support 
concepts for three COAs in a 20-minute timeframe. 


EAWST 


I meet this requirement. 
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6. The system shall allow operators to create a scheme of maneuver for the 
logistics network. 

Requirement based on mission analysis and potential task that an S4 must 
execute. 


LAWST taeetsi this requirement. 

7. The system shall allow operators to set the maximum capacity for each 
friendly asset and unit. 


Requirement based on mission analysis and potential task that an S4 must 


execute. 


LAWST toestsi this requirement. 


8. The system shall allow operators to set objective DOS (Days of Supply) 
for friendly units. 

Requirement based on mission analysis for S4 to vary the DOS based on 
mission requirements and COA. 

LAWST me^ this requirement. 

9. The system shall allow operators to input supply consumption, based on 
OPTEMPO, for each type of friendly asset. 

This requirement is based on the mission analysis and the requirement to surge or 
maintain supply levels 

LAWST mee tsi this requirement. 

10. The system shall allow the input or import of friendly unit information. 

This is a requirement from the Mission analysis, during the planning process, the 
S4 needs to determine available forces to support a COA. 


LAWST taeetsi this requirement 
11 . 


The system shall allow operators in upload friendly asset information from 
an external file. 


Information should be available for operators to upload. Creating data bases for 
every unit is time intensive and infeasible during a planning process. 
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LAWST meets! this requirement. 

12. The system shall allow operators to input Friendly asset information 
manually. 

This requirement is related to requirement 11. 


LAWST mgstsj this requirement. 

13. The system shall provide a mechanism to input friendly maneuver 
graphics within 40 seconds. 

Logisticians need a basic framework of a COA to build the network that supports 
his or her units. 


LAWST meet this requirement. 

14. The system shall provide a mechanism to input or import friendly unit’s 
locations within 40 seconds. 


Friendly unit locations during each phase of the operation are required by the 
logistician in order to determine the delivery of supplies to that unit. When the operations 
planners develop the COAs, the unit’s locations are included. 

LAWST partially meets this requirement. LAWST can input locations but will not 
meet time constraints. Even in a spreadsheet, a logistician needs to determine unit names, 
locations, and unit type during COA development. 

15. The system shall provide a mechanism to input supply levels at every node 
in the network within 40 seconds. 


Known quantity of supplies is necessary to prioritize logistics activities and 
understand urgency and risk in the logistics network. 

LAWST partially meets this requirement. LAWST allows operators to specify 
supply levels at every node, however time constraints will not be met, similar to 
requirement 14. 

16. The system shall allow the creation of arcs/routes for the supply network 
within 40 seconds. 


Logisticians must define the routes that will be used during an operation but have 
limited time to build the structure of the supply network during the COA development. 


69 









LAWST partially meets this requirement. While the arcs and routes can be 
created quickly with pre-defined points, it is infeasible to create them all within 40 
seconds. 


17. The system shall be compliant with all DoN regulations for authority to 
operate (ATO) on NMCI networks. 

This is a regulatory requirement that has little to do with the actual operation of a 
system. However, a system that cannot achieve an ATO is generally not used because of 
the difficulty associated with standalone machines. 


LAWST pan achieve! this requirement by working through the ATO process. 


During Wargame: 

Assume 5 minutes per COA, 2 branches or sequels per COA 


18. The system shall allow operators to input branches and sequels identified 
at each decision point during the wargame. 

This is required during a wargame as per the MCPP. 

LAWST meet this requirement. It requires a separate file per COA. 

19. The system shall allow operators to record wargame events in order to 
modify logistics network. 

Often, COAs are changed during a wargame to accommodate for reactions and 
counteractions that are identified during the wargame. These reactions and counteractions 
are generally global and require changes across all platforms 


LAWST to^stsl this requirement. 

20. The system shall allow operators to see immediate results (less than 10 
seconds) of modifying the logistics network based on enemy action. 


The facilitator of a wargame may ask questions of functional area representatives 
such as logisticians that require a near immediate response in order to synchronize all 
functions and to understand the repercussions of any action or counteraction. 


LAWST meet s this requirement. 

21. The system shall allow operators to evaluate the state of the logistics 
network for a specific unit over time. 
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During a wargame where the facilitator prescribes an avenue-in-depth method, a 
logistician needs to be able to follow a unit or number of units to from start to finish 
during an operation. 

LAWST meets] this requirement. 

22. The system shall allow operators to evaluate the state of the logistics 
network at each phase of an operation. 

Like avenue-in-depth, if a facilitator chooses to look at COAs by phase, a tool 
must be able to accommodate this method. 


LAWST taeetsi this requirement. 

23. The system shall allow operators to evaluate the state of the logistics 
networks at each branch and sequel of an operation. 


Every decision point identified by the facilitator of a wargame usually has a 
branch or sequel associated with it. A system supporting the logistician must be able to 
evaluate any branch, sequel or combination. 


LAWST meet this requirement. As described in Chapter IV. 

24. The system shall allow operators to evaluate the state of the logistics 
networks at specified times during an operation. 

Another method for wargaming is key event method; this is where the facilitator 
looks at specific times and places in a CO A during a wargame. 

LAWST meets] this requirement. 

25. The system shall model units down to the platoon level (T), or the 
individual platform or Marine (O). 

Wargaming at any given echelon usually explores units two levels down; for 
example, at battalion level, wargames examine platoon level tasks. 


LAWST toeetsi this requirement. 

26. The system shall allow routes to be adjusted for certain time periods to 
support branches and sequels in 20 seconds or less. 


The time constraints for answers during a wargame are generally tight. A 
logistician needs to be able to answer questions quickly so the wargame can progress. 
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LAWST meets! this requirement. 

27. The system shall allow logistics assets availability to be adjusted for 

certain time periods to support branches and sequels in 20 seconds or less. 


In addition to the structure of the logistics network changing during the wargame, 
the location of assets that are used for transportation may need to be readjusted to support 
certain branches or sequels. Due to time constraints associated with the wargame, 
outcomes need to be realized quickly. 


LAWST partially meets this requirement. Moving assets involves going into each 
logistics node and adjusting the number of assets in each. This could take a few seconds 
to several minutes depending on the number of adjustments that need to be made. 


Analysis: 

The system shall provide the following analysis within 10 seconds when any changes 
are made to the Logistics network: 

Determine agility of the logistics network. 

28. -The system shall determine the amount of time it takes for the network to 
recover to the objective DOS on-hand after the loss of transportation 
assets or closure of an arc. 


Recovery of the logistics network after a major change is a good indicator of how 
robust the network is and how agile the response to issues in the network is. 

LAWST meet this requirement. This can be done with LAWST, scripted 

sorties allow unscheduled assets to deliver supplies but there is no function to remove 
assets or routes at a given time during the simulation. 

29. -The system shall determine the DOS at each friendly unit in excess of the 
objective over time. 

Delivery of supplies is generally not exact, with respect to the amount. Sometimes 
units request additional supplies for certain times and places; other times like during 
movement, they only want the basic 3 DOS on hand. It is important to determine where 
the supply network can flex when supplies or transportation assets may be lacking. 


LAWST 


I meet this requirement. The algorithm in LAWST only fills units 


to the objective DOS as specified by the operator. Excess supplies are not delivered. 
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30. -The system shall determine the utilization rate of transportation assets 
within the logistics networks. 

Flexibility requires that options can be determined. High utilization rates are 
important to identify, this signifies that there is little availability to surge additional 
supplies in a given area. 


LAWST liaeetsi this requirement. 

31. -The system shall determine the number of excess transportation assets 
within the logistics network over time. 

This requirement is similar to 30. 


LAWST meets this requirement. This requirement may be merged or rectified 

with requirement 30 after some trade-offs are made. 

Determine efficiency of the logistics network: 

32. The system shall determine the efficiency of the network with respect to 
number of transportation assets used. 

Logisticians may want to use fewer assets if possible, to reduce costs. 


LAWST meet this requirement. 

33. The system shall determine the efficiency of the network with respect to 
fuel used to distribute supplies. 


Logisticians may want to determine the most efficient network with respect to 
fuel used during operations. This is also a key question that E20 is interested in. 

LAWST meets this requirement. 

34. The system shall determine the efficiency of the logistics network with 
respect to an estimated cost of fuel used to deliver supplies. 

It is important to look at the estimated cost of an operation with respect to the 
amount of fuel used. This is an important metric to determine savings for one COA vs. 
another. 


LAWST 


I meet this requirement. 


Determine fuel used by each type: priority information for E20 
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35. -The system shall determine the fuel used by eaeh distribution node in the 
network. 

36. -The system shall determine the fuel used by eaeh platform, both 
maneuver and logisties platforms. 

37. -The system shall determine the fuel used by each type of platform. 

38. -The system shall determine the overall fuel used over time. 

39. The system shall estimate the cost, in terms of estimated dollars and fuel 
costs to execute each COA. 

For requirements 35-39, it is important to determine where the greatest impact is 
with respect to fuel usage. 

LAWST partially meets (5) these requirements. Formatted reports are not built 
into LAWST, however the data is available after the simulation is complete. 

Identify Issues: 

40. The system shall determine where assets are insufficient to provide the 
objective DOS within the logistics network. 

It is important to pinpoint where the logistics network is weakest. 

LAWST mee tsj this requirement. 

41. The system shall determine where supplies are below the objective DOS 
within the logistics network. 

Logisticians need to determine where and when to surge supplies to keep up with 
demand. 


LAWST toeetsi this requirement. 


42. The system shall determine where supplies are insufficient to meet 
demand within the logistics network. 


Similar to requirement 41, maybe combine during requirements trade-off. 


LAWST liaeetsi this requirement. 


43. The system shall assess and identify areas of critical vulnerability, what is 
most susceptible to interdiction. 
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It is important to examine high utilization arcs and nodes to determine which 
portions of the logistics network is most critical to the success of a mission. This allows a 
better understanding where additional redundancy or force protection is required. 

LAWST meet this requirement. While a deeper analysis can be 

conducted using the data that LAWST produces. The risk scores help to determine where 
utilization, throughput, etc., is high but it does not show, for instance, where a high 
capacity arc with relatively little throughput could be lost and have severe impact to the 
logistics network. 

Optimize: 

44. The system shall provide recommendations, based on excess logistics 
assets and available supplies, how to improve the network efficiency. 

With the complexity of any logistics networks, a logistician needs help identifying 
options to best improve a logistics network. With the number of factors and levels 
associated with these networks, there are thousands of options to improve the network. 


LAWST 


I meet this requirement. 


45. The system shall provide recommendations, based on excess logistics 
assets and available supplies, how to improve the network effectiveness 
with respect to delivering objective DOS. 


Similar to requirement 44, it is important to determine how the network should be 
optimized. Logisticians should be able to determine which factors are the most important 
to their commander when analyzing a COA. This requirement may be combined with 
requirement 44 in requirements trade-off. 


LAWST 



meet this requirement. 
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